Modern computer installations generate, manipulate, and store enormous quantities of data. Data base management systems have emerged as an indispensible component of such installations, serving the purpose of promoting efficient data storage and program design, enhancing file maintenance and modification, and eliminating data redundancy. The typical data base management system (DBMS) includes programs which interface with designers and users, accept and understand models or tables for subsequent use in organizing data, organize data according to the models or tables, store and retrieve the data in the actual data base contained in a computer storage subsystem, perform queries on the data, and generate reports based on the stored data.
A DBMS may be designed to store data according to any of a variety of data models, where the data model is the basic organizational concept for the underlying data base. These models, or schemas, for data base organization can be divided into several different classes, including hierarchical, network, relational, and entity-relationship. A detailed discussion of these types of databases may be found in "The Database Book," by Mary E. S. Loomis, Macmillan Publishing Company, New York, N.Y. 10022 (1987). The present invention is applicable to all of the above database schemas. The preferred embodiment is described with particular reference to the entity-relationship modelling methodology provided by the Repository Manager/MVS product, which uses the DB2 relational DBMS as a back end to manage the storage and retrieval of data on the computer hardware. Entity-relationship databases are discussed in "The Entity-Relationship Model-Towards a Unified View of Data," by Peter Chen, ACM Trans. on Data Base Systems, Vol. 1 (1976). Relational databases and DB2 in particular is discussed in "IBM Database 2: General Information," IBM Publication GC26-4373 (1990). The Repository Manager/MVS product is discussed in "Repository Manager: Concepts and Facilities," IBM Publication SR21-3608 (1990).
A significant problem in maintaining any data base whose data entries represent objects, events, people, or relationships in the real world, is that although those things may change over time, the typical DBMS maintains only a single version of any given entry, making it impossible to concurrently represent a thing in its past, present, and future states. A second significant problem, which arises in maintaining a data base which is shared among a plurality of users, involves the toleration of concurrent but independent work on the same data entries by different users without sacrificing the semantic consistency of the data. Yet a third problem in maintaining a data base involves maintaining a record of the state of the data base itself as it existed at given times in the past. Such information is often needed for error recovery and for audit-trail purposes. Typical solutions to this problem involve taking "snapshots" of the data base and logging change activity, so that if necessary the data base can be "reconstructed" as it existed at some point in the past. This reconstruction is usually a time-consuming batch procedure, and a system so constructed cannot allow the past and current data bases to be accessed concurrently.
A solution to all of these problems is to maintain versions of the data entries. These versions may correspond to the different states of the real-world things represented, or to work in progress by different users. Such an approach is called versioning, and in general requires that the DBMS control the creating of the versions and all access to them, both to assure the semantic consistency of the data in all its versions, and to free users from the need to deal with the additional complexity that such a versioning scheme requires. Users of non-versioned data base systems sometimes simulate versioning by giving qualified names to the data base entries. However, this approach is undesirable, because it conceals from the DBMS the true identity of the things represented, and makes it impossible for the DBMS to verify the semantic consistency of the data base.
The generally preferred approach to implementing versioning is to provide direct versioning of entries in the DBMS, with the versioning managed by the DBMS to preserve the semantic validity of the data in the system. Such a system provides both parallel and serial versioning, with the capability for the user to define a hierarchy of versions, and to direct the DBMS to move versions of data from one hierarchy level to another. It also provides historical versioning of the database, allowing the user to view the data as it existed at any arbitrarily-selected time in the past. It provides a simplified programming interface that allows a user tool to interact with the data as though it were not versioned, the specification of which version is seen being made outside the program.
For a VDMS to serve the needs of a user community, it must tolerate the co-existence of multiple approaches to versioning, some or all of which may not be complementary. This is because different projects, or different processes, dealing with the same entity and relationship types, need variant hierarchies having different topologies. For example, the program development process for the Payroll project, which is large, may require four levels, with a variant hierarchy of: ##STR1## The smaller Inventory project may need only three levels. Its variant hierarchy would be: ##STR2##
Parts from both projects must sometimes be accessed simultaneously, but a single variant hierarchy that satisfies both projects would require a superfluous "Integration" version level and promotions through that level for parts in the Inventory project.
Thus multiple hierarchies would generally appear to be a desirable feature in a VDMS. However, simply defining multiple hierarchies creates two new problems: determining which parts belong to which hierarchy; and allowing visibility to a tool of only those parts in a certain hierarchy or hierarchies. For instance, a user working on the Inventory project probably would not want visibility to Payroll parts, while a project administrator might need to see parts from all projects.
Heretofore, no method has been available which solves these problems and thus provides a VDMS with simultaneous visibility to multiple variant hierarchies.